<html>
 <head>
  <meta charset="UTF-8">
 </head>
 <body>
  <h1 data-lake-id="3c4e0a25" id="3c4e0a25"><span data-lake-id="ufaaadb88" id="ufaaadb88">典型回答</span></h1>
  <p data-lake-id="u766a8114" id="u766a8114"><br></p>
  <p data-lake-id="u5ac8aac9" id="u5ac8aac9"><span data-lake-id="u651be76a" id="u651be76a">分布式数据库，即所谓的NewSQL。主要代表TiDB（pingcap）、OceanBase（蚂蚁）、Spanner（google）。与传统关系型数据库相比：</span></p>
  <p data-lake-id="u0ef6eb7e" id="u0ef6eb7e"><br></p>
  <ol list="ua07c0c8c">
   <li fid="u36afa3cd" data-lake-id="u02a3056d" id="u02a3056d"><strong><span data-lake-id="u62d87059" id="u62d87059">性能高</span></strong><span data-lake-id="ub979a234" id="ub979a234">：在亿级别以上，读和写都会高于传统关系型数据库（MySQL、SQLServer等），在亿级别以下略逊色与传统关系型数据库</span></li>
   <li fid="u36afa3cd" data-lake-id="u46c718ec" id="u46c718ec"><strong><span data-lake-id="u98d07135" id="u98d07135">可维护性</span></strong><span data-lake-id="u4b8d5831" id="u4b8d5831">：TiDB、OceanBase都以开源的形式存在，其生态也比较贴近于现代数据库的需求（如完全支持云原生），有较好的社区文档、企业免费的培训课程</span></li>
   <li fid="u36afa3cd" data-lake-id="u114004fc" id="u114004fc"><strong><span data-lake-id="u3d368de6" id="u3d368de6">可靠性</span></strong><span data-lake-id="uee2af70f" id="uee2af70f">：由于分布式的特性，通过副本冗余的方式提升整个集群可靠性。同样由于分布式的特性，无法严格且完全的实现真正意义上的ACID，从事务的角度来看可靠性降低了。</span></li>
   <li fid="u36afa3cd" data-lake-id="ufe506d2f" id="ufe506d2f"><span data-lake-id="u1ab35095" id="u1ab35095">可</span><strong><span data-lake-id="u1307aff0" id="u1307aff0">扩展</span></strong><span data-lake-id="ufadb92f9" id="ufadb92f9">性：分布式的特性就在于近乎无限的水平可扩展，增加集群节点数量可大幅度提高集群的QPS和存储能力。Spanner甚至实现了全球部署。</span></li>
   <li fid="u36afa3cd" data-lake-id="u74e79e19" id="u74e79e19"><span data-lake-id="ue6b68f00" id="ue6b68f00">用户体验：兼容大部分SQL标准，但也是由于分布式的原因，很多传统关系型数据库的特性（SQL语法、其他功能）无法支持，如：无法保证自增id的连续性，有限的支持事务的强一致性(对性能略有损失)，天生分布式不支持单机部署（小型业务无法使用）。TiDB与MySQL思想类似，也存在存储引擎概念，通过存储引起实现了OLAP和OLTP两种模式，插入数据能随时进行在线事务操作，也可以进行实时的离线分析操作。</span></li>
  </ol>
  <p data-lake-id="uaae40c14" id="uaae40c14"><br></p>
  <h1 data-lake-id="b3a8e5e2" id="b3a8e5e2"><span data-lake-id="ua431c12d" id="ua431c12d">扩展知识</span></h1>
  <p data-lake-id="u9ecb70a6" id="u9ecb70a6"><br></p>
  <h2 data-lake-id="J7ukW" id="J7ukW"><span data-lake-id="u8a4547ae" id="u8a4547ae">有了MySQL为啥还要有分布式数据库？</span></h2>
  <p data-lake-id="u060a1659" id="u060a1659"><span data-lake-id="uf72f9bca" id="uf72f9bca"><br>
    其实能用上分布式数据库的公司数据量和QPS已经非常庞大了。很难通过MySQL解决数据量和高QPS的问题了。</span></p>
  <p data-lake-id="ub4a932f6" id="ub4a932f6"><span data-lake-id="ue56c3203" id="ue56c3203">​</span><br></p>
  <p data-lake-id="u053123bd" id="u053123bd"><span data-lake-id="ufbbc043d" id="ufbbc043d">MySQL在应对大数据量的时候通过采用分库分表的方案，应对大量读QPS的场景方案是进行读写分离，而写TPS很难提高，分库分表会带来诸多问题。</span></p>
  <p data-lake-id="u354ff96f" id="u354ff96f"><span data-lake-id="u9ba31ed1" id="u9ba31ed1">​</span><br></p>
  <p data-lake-id="u9058e30e" id="u9058e30e"><br></p>
  <p data-lake-id="u2872879d" id="u2872879d"><span data-lake-id="u2d07909a" id="u2d07909a">读写分离会带来的问题：</span></p>
  <p data-lake-id="u9b219ac9" id="u9b219ac9"><br></p>
  <ol list="u5870e691">
   <li fid="u0643e342" data-lake-id="u0817604f" id="u0817604f"><span data-lake-id="uda46881b" id="uda46881b">主从复制存在延迟，存在写后读依赖的场景，只能强制读主，进而对主产生了压力</span></li>
   <li fid="u0643e342" data-lake-id="u43e2fcf4" id="u43e2fcf4"><span data-lake-id="u9906f65b" id="u9906f65b">读写分离需要应用感知主和从的存在</span></li>
   <li fid="u0643e342" data-lake-id="u96f4aa5d" id="u96f4aa5d"><span data-lake-id="u90891205" id="u90891205">使用cluster方案维护主从切换成本高</span></li>
   <li fid="u0643e342" data-lake-id="uf26bddab" id="uf26bddab"><span data-lake-id="u1aba4c5a" id="u1aba4c5a">纯主从复制方案单实例写tps有限，从只能提高读的并发度</span></li>
  </ol>
  <p data-lake-id="u5764f456" id="u5764f456"><br></p>
  <p data-lake-id="u9fbcefc1" id="u9fbcefc1"><span data-lake-id="udd8a7815" id="udd8a7815">因此，MySQL官方提供了Cluster方案，但对主从选举时采用了复杂的paxos算法，可维护性和性能都大幅度降低，业内并不买账，依旧使用传统的分库分表、主从复制。</span></p>
  <p data-lake-id="u5982d169" id="u5982d169"><span data-lake-id="u6eb9c41a" id="u6eb9c41a"><br>
    总的来说MySQL可维护性和可扩展性较差。</span></p>
  <p data-lake-id="u1faeda8f" id="u1faeda8f"><br></p>
  <p data-lake-id="u2e7952db" id="u2e7952db"><span data-lake-id="u13f946f4" id="u13f946f4">在分布式数据库中，</span><strong><span data-lake-id="u2cb2383a" id="u2cb2383a">从TiDB来说，重点解决了可维护性和可扩展性的问题。</span></strong></p>
  <p data-lake-id="u69953986" id="u69953986"><span data-lake-id="ufdcb5e96" id="ufdcb5e96">​</span><br></p>
  <p data-lake-id="uc5ce5060" id="uc5ce5060"><span data-lake-id="ue3069b5a" id="ue3069b5a">TiDB通过pd节点管理数据的自动分片，调度，倾斜自动迁移，热点自动迁移，自动选主（采用轻量的raft协议）等功能。数据节点单机使用LSM树作为底层存储结构，大幅度提升机械磁盘写的IOPS。</span></p>
  <p data-lake-id="u420493ab" id="u420493ab"><span data-lake-id="u1dd552cd" id="u1dd552cd">​</span><br></p>
  <p data-lake-id="u4cc854ee" id="u4cc854ee"><span data-lake-id="u47b364aa" id="u47b364aa">本质上内部分片采用范围分片的策略，然后整个集群构成了一个树状结构，进行聚合，分页查询。分布式中时间是一个很重要的东西，无论是事务的id生成，还是MVCC（多版本并发控制）都依托于时间，在计算机中即使是采用NTP服务也无法解决时间漂移的问题。</span></p>
  <p data-lake-id="uf7bac259" id="uf7bac259"><span data-lake-id="u831d76a3" id="u831d76a3">​</span><br></p>
  <p data-lake-id="ud087ce9e" id="ud087ce9e"><span data-lake-id="ua2851b60" id="ua2851b60">TiDB通过pd节点管理时间，计算节点、数据节点都从pd节点进行同步。而Spanner采用了一个硬件设备（艳原子钟）确保数据中心的时间非常精准，从而实现了全球数据库部署，即跨国际的时间同步策略保证了事务的正确。<br></span><code data-lake-id="uf4bc430d" id="uf4bc430d"><span data-lake-id="u5685e0ae" id="u5685e0ae">题外话： Leslie Lamport 在 1978年提出了分布式逻辑时钟算法，有兴趣可以读读其论文</span></code></p>
  <p data-lake-id="ua8f327f3" id="ua8f327f3"><br></p>
  <p data-lake-id="u0e03d9e0" id="u0e03d9e0"><span data-lake-id="u74615cdb" id="u74615cdb">由于是分布式数据库，有限支持id自增，有限支持强一致的事务(对性能略有损失)。其弊端：</span></p>
  <p data-lake-id="u1efe9c7d" id="u1efe9c7d"><br></p>
  <ol list="uf6433dc3">
   <li fid="u50d8415a" data-lake-id="u953a23a3" id="u953a23a3" data-lake-index-type="true"><span data-lake-id="ubcd38fa6" id="ubcd38fa6">天生分布式，不支持单机部署，基本不适合小业务量的应用</span></li>
   <li fid="u50d8415a" data-lake-id="ud79963f5" id="ud79963f5" data-lake-index-type="true"><strong><span data-lake-id="u0dadc04d" id="u0dadc04d">由于分布式，事务隔离级别弱，无法完全实现ACID</span></strong></li>
   <li fid="u50d8415a" data-lake-id="u1388cae8" id="u1388cae8" data-lake-index-type="true"><span data-lake-id="udcb992ff" id="udcb992ff">实测在亿级以下的读写请求比mysql的性能略低一些</span></li>
  </ol>
  <p data-lake-id="u33dda40c" id="u33dda40c"><br></p>
  <p data-lake-id="u55402c94" id="u55402c94"><span data-lake-id="ud371a6f4" id="ud371a6f4">总的来说，虽然tidb承诺金融级别的分布式数据库，但是选择用在核心链路上还要深思熟虑。用在支付链路上曾遇到过因为tidb 慢查询导致整个集群崩溃，其原因是tidb查询分析器有bug导致选择错了查询计划。</span></p>
  <p data-lake-id="u6ea084cd" id="u6ea084cd"><span data-lake-id="ud0eea767" id="ud0eea767"><br>
    分布式数据库是技术和商业发展的必然，人类产生的数据量越来越大，传统关系型数据库也在逐渐往分布式数据库上过度（如MySQL的Cluster方案），人们应该逐渐接受分布式带来的问题，接受并能够解决事务不是那么强一致。</span></p>
  <p data-lake-id="u1cff9ebf" id="u1cff9ebf"><br></p>
  <p data-lake-id="u94fad475" id="u94fad475"><span data-lake-id="u91f49954" id="u91f49954">值得一读的论文：</span></p>
  <p data-lake-id="u11d73513" id="u11d73513"><br></p>
  <ul list="uc085f1b3">
   <li fid="ue1243a02" data-lake-id="uf4bc755e" id="uf4bc755e"><span data-lake-id="ub1718640" id="ub1718640"> Google的Spanner虽然闭源，但其被奉为分布式数据库的鼻祖，TiDB大量参考了该论文的实现。有兴趣的小伙伴可以读读 《Spanner: Google’s Globally-Distributed Database》 </span></li>
   <li fid="ue1243a02" data-lake-id="uafe11bcb" id="uafe11bcb"><span data-lake-id="ua23e7034" id="ua23e7034"> TiDB完全开源免费，社区非常活跃，在国内外大厂用的很多。有兴趣的小伙伴可读读 《TiDB: a Raft-based HTAP database》 </span></li>
   <li fid="ue1243a02" data-lake-id="uc6a0428b" id="uc6a0428b"><span data-lake-id="ua8786e9a" id="ua8786e9a"> Leslie Lamport 逻辑时钟 《Time, Clocks, and the Ordering of Events in a Distributed System》 </span></li>
  </ul>
 </body>
</html>